Measurement and control tasks in the industrial sector are often crucial for safety. Customer applications require safeguarding the accuracy and the availability of measurement and control variables of the respective automation. Integrity and availability of data is, in most cases, more relevant than the likewise important confidentiality. The special safety relevance of devices of measurement and control technology, such as measuring devices, controllers, sensors, actuators, monitoring circuits, warning displays, fieldbus network technology, etc., increases because the consequences of malfunctions of or tampering with these devices may be potential hazards, such as explosions, discharge of hazardous materials/gases, etc.
Automation solutions consist of a plurality of independent subcomponents, such as controllers, sensors, network infrastructure components such as routers, etc. These subcomponents can each be designed separately as an individual device of measurement and control technology or also be at least partially integrated into a device. Today, each of these subcomponents typically contains its own software components so-called firmware. In addition, each individual device, such as a field device for pH measurement, can also be composed of several submodules that each contains its own firmware for example, a subsystem having a microcontroller for each fieldbus interface, a subsystem for measured value signal processing, as well as a subsystem for analog-digital conversion. The firmware is embedded in the microcontroller in each case. In addition to the integrity of the data transfer to the communication interfaces (fieldbus, Ethernet, wireless HART, etc.) of devices or subcomponents, the integrity of the measured value processing in the subcomponents (transmitter, sensor) is crucial for the accuracy of the measurement.
A possible attack scenario is that an attacker slips manipulated firmware components to the operator of an automation system. Thus for example, within a temperature sensor the temperature measured values measured by the sensor could be intentionally manipulated within the firmware so that the control system connected to the sensor reports a non-critical operating temperature, while, in reality, the monitored process has a greatly elevated temperature which could lead, for example, to the explosion of a tank.
For a successful attack, it is usually sufficient to manipulate the firmware of an arbitrary subcomponent within an attacked device or within an attacked system containing a plurality of devices.
A concrete example using a pH-measuring point: a pH-measuring point generally contains a pH and a temperature transducer, which are usually combined into a single device. The device further contains device electronics connected to the transducer. These can include, for example, one or more microcontrollers for analog-digital conversion of the output of the transducer, an additional microcontroller for processing measurement signals, a fieldbus interface for transmission of the measurement signals via a fieldbus, and a system that handles the operation of fieldbus interfaces. If an attacker would like to manipulate the transmitted temperature measured values of such a pH measurement point, for example, he can achieve this goal by selectively manipulating the firmware within the microcontroller for analog-digital conversion of the output signal of the temperature transducer or the firmware of one of the other subcomponents of the device.
The reliable repulsion of an attack launched using manipulated firmware components thus requires that the firmware of all involved subsystems and subcomponents be checked.
In the past, it was often customary that the integrity of firmware did not need to be considered for such security concerns, because programming of firmware took place using so-called metal masks during chip production or, in the case of so-called flash memory areas, reprogramming was, due to design constraints, only possible at the production facilities of the device manufacturer for a component. The current state of the art, however, is that it is possible to import new firmware into all subcomponents a so-called firmware update at any time during the runtime, even in the field.
Ensuring the integrity of all firmware components involved, without exception, is therefore crucial for ensuring the complete integrity of the system.
As a consequence, both the “large” systems having lots of memory and very computationally weak microcontroller systems must be secured. In the cryptographic context, the necessary so-called “authenticity” of firmware is spoken of here, in which the receiving system checks that the firmware component to be received in the course of the update is authentic meaning, for example, actually created by the device manufacturer, and not by a possible attacker.
Two large classes can be distinguished in regards to the cryptographic verification of authenticity:                Symmetric check sum methods using authentication codes (so-called message authentication codes, abbreviation: MAC), such as AES-CBC, HMAC-MD5, HMAC-SHA256, Chaskey, Chaskey-LTS, Galois field-based MAC's such as the authentication components in AES-GCM, as well as primary number-based methods such as Poly1305, etc.        Asymmetric signature methods such as RSA-based signatures, ECDH signatures on elliptical curves, EdDSA signatures, hash-based signature methods, DSA signatures, etc.        
The two classes of methods can be used via cryptographic methods, hereinafter also described as encryption methods, to generate an authentication datum, e.g., a check sum or a digital signature, which can be delivered together with the firmware component that serves to update the firmware of a system. Using the authentication datum and key information, the receiving system can then verify whether the delivered firmware component is authentic or not.
The two aforementioned method classes are differentiated, on the one hand, in that, for symmetric methods, the exact same key is used both for generating the authentication datum as well as for verifying the authentication datum, whereas different keys are used in asymmetric methods. On the other hand, the two method classes differ in their complexity and with regard to their need for computing time and/or memory, and in the code size of the methods implemented in the software.
In symmetric methods, each entity that can conduct an authentication test can itself also generate a correct check sum as an authentication datum, since the key used must be “symmetrically” available to the two parties involved. In asymmetric methods, different keys are present on either side (generation and testing).
Symmetric check sum methods today are so stable and secure in the view of many cryptographers that mathematical attacks on the basic algorithms can practically be excluded, if key lengths of more than 80 bits are used. Today, symmetric keys of at least 128 or 256 bits long are often recommended.
However, there is a major problem with using symmetric methods in the context of systems having small microcontrollers. For verifying the authenticity of a newly offered firmware component, it is necessary for the symmetric key to be kept in the persistent memory of the system. In conventional microcontrollers, however, this memory cannot be effectively protected against unauthorized reading. It's true that there are electronic building blocks from the so-called smart card IC class, which, for example, protect the persistent memory of a controller against unauthorized access by means of special metal coverings of the memory area and sophisticated protection mechanisms. Such countermeasures are, however, not used in conventional microcontrollers.
It is thus possible for an attacker to improperly obtain the symmetric key information relatively easily for example, by opening the housing or bypassing the access restriction of an interface for debugging software (debugger interface). The attacker can then easily generate a correct check sum for his manipulated firmware components and plant them in a subsystem without causing an error.
The main advantage of the symmetric methods is that they can be efficiently implemented in systems having low processing power. In particular, this requires very little source code and CPU power. So, for example, a MAC algorithm such as Chaskey LTS can be implemented in an ARM Cortex M0 CPU having an approximate program length of just 512 bytes. In contrast to asymmetric signature methods, a so-called collision-resistant hash algorithm, for example, which typically requires larger constant tables and a relatively large amount of program code, is not mandatory as a subcomponent.
The main difference between symmetric and asymmetric methods is that, in asymmetric methods for generating a signature as an authentication datum, another key is used for the verification of the signature. In this case, the key for signature generation is referred to as a “private” key, and the key used for verifying the signature is referred to as a “public” key. The private key used for the signature of a firmware component can thus be kept exclusively in a secure environment for example, inside an access-controlled area within the development department at the device manufacturer. This private key can, therefore, be much more effectively protected against potential attackers than in an unprotected memory stored in a field device. When an asymmetric signature is used, only the non-critical public key, which an attacker cannot use on his own to sign a manipulated firmware, is inside the persistent memory of the systems of the device containing the microcontroller.
For asymmetric methods today, considering the possible attacks against the mathematical methods, key lengths of at least 2048 bits (in methods using DSA or RSA based upon methods based upon factorization of large numbers and groups of prime number fields), or >230 bits for methods based upon elliptical curves, are required. Alternative methods, e.g., the so-called Merkle signature based upon hash trees, code-based signatures (McEliece), or so-called lattice-based signature methods (for example, LWE, Learning with Errors) require far longer keys of 10 KB and more and are, therefore, not often used in practice. In the context of high-performance computing systems, such as web servers on the Internet, signatures based upon methods like RSA, DSA, or ECDSA are widely used, e.g., in so-called certificates, as they are used by keyed protocols such as HTTPs or TLS.
The challenge is that these methods require significantly more computing resources than symmetric methods because of the complex algorithms and large key lengths. Thus, even an optimized software implementation of asymmetric cryptography in small microcontrollers already needs about 10 KB of memory (Des. Codes Cryptogr. (2015) 77: 493-514). In comparison to symmetric methods, therefore, at least a 10- to 100-fold larger memory requirement for the associated program code is to be expected.
Inside an industrial control device, there are typically individual components that provide sufficient resources for the standard procedures. For example, within a pH sensor, a CPU responsible for the fieldbus communications could provide sufficient memory and processing power. As explained above, however, this is not sufficient for securing an individual subsystem. Instead, all firmware components involved must be protected, even in the smaller subsystems for example, for the analog-digital conversion near the physical transducer.
Outsourcing the signature verification to only the high-performance CPU's of a component entails the risk that errors in the protocols within one component can affect the other components. That is, the security of a firmware component (for example, for A/D conversion) is then a function of the correctness of another firmware component (for example, fieldbus CPU), which may in some cases be under the control of another organizational unit, or even an outside company, and cannot be verified. This increases the number of possible error sources in conception and implementation.
A feature of security is that systems of lower complexity are always desirable. In practice, this is frequently attained only if each CPU in a firmware update is, on its own, completely responsible for the firmware authentication, the verification thus occurring de-centrally. In practice, secure systems can often be designed only in this manner.
The following considerations are important for the firmware update process in an embedded system. The computing system typically is made up of a processing unit, as well as a RAM memory for dynamic data and a (flash) ROM memory for persistent data. The processing unit (CPU) obtains the machine instructions from the ROM memory, and persistent data, such as cryptographic keys, are also stored there.
The current state of the art is that microcontrollers are equipped with a built-in ROM memory called flash technology. Flash memory usually dominates the silicon surface of the microcontroller and is thus the critical cost component in the production of the microcontroller chips. For reasons of cost, therefore, building blocks tailored precisely to just the memory needed are typically used. A typical embedded system thus usually provides no more than just the RAM and flash ROM needed to be able to temporarily store the previous as well as the “new” firmware components during a firmware update.
For this reason, a distinction is usually made between two firmware components: a so-called bootloader component (hereinafter referred to as bootloader, for short) and an application component (hereinafter also referred to as application, for short). In a typical microcontroller having, for example, a total of 64 kB of flash memory, the total firmware consists of, for example, a bootloader having, for example, 4 kB of flash and an application having 59 kB of flash and 1 kB of data memory.
The task of the bootloader is, therefore, to enable an exchange of the application firmware. To this end, the application area of the flash is first erased by the bootloader. In many cases, the flash in microcontrollers is separated at this point by hardware into a so-called “bootloader” section and an “application” section, wherein the bootloader and application sections can be erased separately. In such systems, the maximum possible size of the bootloader is thus limited by the hardware to lengths of typically 4 or 8 kB. After the erasing process, the application is no longer available. Next, a new application firmware is sent to the bootloader via an external data interface and then re-installed in the flash memory.
It is important in the context of generation and/or verification of cryptographic authentication data that the complete firmware components transmitted in the update must be used for the generation and verification of an authentication datum. For obvious reasons, verification of the authentication datum from the bootloader part of the software is required in the type of firmware upload described above.
As one can easily see from the aforementioned typical example, it is, predictably, not possible to implement secure asymmetric cryptographic methods (typically, having at least 10 kB code length) under the constraints of the code size restriction of the bootloader. In the context of normal application (in the example, 59 kB of code), such methods are, however, very easy to implement.